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ABSTRACT 

Studies of Aspect-Oriented Programming (AOP) usually focus on 
a language in which a specific aspect extension is integrated with 
a base language. Languages specified in this manner have a fixed, 
non-extensible AOP functionality. In this paper we consider the 
more general case of integrating a base language with a set of do- 
main specific third-party aspect extensions for that language. We 
present a general mixin-based method for implementing aspect ex- 
tensions in such a way that multiple, independently developed, dy- 
namic aspect extensions can be subject to third-party composition 
and work collaboratively. 

1. INTRODUCTION 

A current trend in Aspect-Oriented Programming (AOP [26j) is the 
usage of general-purpose AOP languages (AOPLs). However, a 
general-purpose AOPL lacks the expressiveness to tackle all cases 
of crosscutting. A solution to unanticipated crosscutting concerns 
is to create and combine different domain-specific aspect exten- 
sions to form new AOP functionality 1421 . As of yet, there is no 
methodology to facilitate this process. 

Studies of AOP typically consider the semantics for an AOPL that 
integrates a certain aspect extension, Exti, with a base language, 
Base. For example, Exti might be (a simplified version of) As- 
pectj 1251 and Base (a simplified version of) Java (3). The se- 
mantics for the integration Base x Exti is achieved by amend- 
ing the semantics for the base language. Given a pair of programs 
{base, aspect t ) 6 Base x Exti, the amended semantics explain 
the meaning of base in the presence of aspect 1 . 

Unfortunately, the semantics for the aspect extension and that for 
the base language become tangled in the process of integration. 
Consequently, it is difficult to reuse or combine aspect extensions. 
For each newly introduced aspect extension, say Ext2, the seman- 
tics for Base x Ext2 needs to be reworked. Moreover, given the 

*This research was supported in part by the National Science Foun- 
dation (NSF) Science of Design program under Grant Number 
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semantics for Base x Exti and the semantics for Base x Ext2, the 
semantics for Base x Exti x Ext2 is undefined even though Exti 
and Ext2 are both aspect extensions to the same base language. 

In this paper we resolve this difficulty by considering a more gen- 
eral question: 

The aspect extension composition question: Given a base 
language, Base, and a set {Exti, . . . , Ext n } of independent as- 
pect extensions to Base, what is the meaning of a program base £ 
Base in the base language in the presence of n aspect programs 
(aspect 1 , . . . , aspect ) £ Exti X ■ ■ ■ X Ext„ written in the n dif- 
ferent aspect extensions ? 

Ability to compose distinct aspect extensions is of great practical 
importance (Section|2j. Addressing the general composition ques- 
tion also provides in the special case where n = 1 a better encap- 
sulation of the semantics for a single aspect extension. 

1.1 Combining Two Aspect Extensions 

Answering the aspect extension composition question is difficult 
even for n = 2. Let MyBase be a procedural language, and con- 
sider two independent, third-party aspect extensions to MyBase. 
The first, HisExti, capable of intercepting procedure calls and sim- 
ilar in flavor to AspectJ. The other, HerExt2, an aspect extension 
to MyBase capable of intercepting calls to the primitive division 
operator for catching a division by zero before it even happens (as 
opposed to catching a division by zero exception after it occurs), 
a capability that AspectJ lacks. 1 Both call interception (e.g., 1271 ) 
and checking if a divisor is zero (e.g., 1 5 28 18 1) are benchmarks 
often used in connection with aspects. 

W.l.o.g., assume HisExti is created before HerExt.2 is even con- 
ceived. If HisExti is to eventually work collaboratively with an- 
other aspect extension, e.g., HerExt2, the implementation of His- 
Exti must take special care to expose its AOP effect, and only its 
effect, in terms of MyBase. This is because an aspect^ program 
written in HerExt2 would need to intercept divisions by zero not 
only in the base program base but also in advice introduced by an 
aspect 1 program written in HisExti. 

Failing to reify a division by zero in aspect 1 might cause a false- 
negative effect in HerExt2. Meanwhile, aspect 2 must not intercept 
divisions by zero, if any, in the implementation mechanism of either 
HisExti or HerExt2. Reifying a division by zero in the implemen- 
tation mechanism might cause a false-positive effect in HerExt2. 

'AspectJ can neither advise primitives nor arguments. 
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Similarly, aspect 1 must intercept not only procedure calls in base 
but also any matching procedure call introduced by aspect^ . aspect 1 
must not, however, intercept internal procedure calls that are a part 
of the implementation mechanism of either HisExti or HerExt.2. 

Note that generally aspect extensions present incompatible levels of 
AOP granularity |30}. In our example, aspect j is not expressible 
in HerExt.2, and aspect^ is not expressible in HisExti. Therefore 
the problem of integrating the two cannot be reduced to translating 
aspect L to HerExt.2 or translating aspect^ to HisExti and using 
just one aspect extension. This distinguishes our objective from the 
purpose of frameworks (like X Aspects 1 38 ]) that rely on the use of 
a general purpose AOPL (like AspectJ). 

In the sequel, a base mechanism denotes an implementation of a 
base language semantics, an aspect mechanism denotes an imple- 
mentation of an aspect extension semantics, and a multi mechanism 
denotes an implementation of a multi-extension AOPL. 

1.2 Objective and Contribution 

We describe a general method for implementing the base mecha- 
nism and the aspect mechanisms in such a way that multiple, inde- 
pendent aspect mechanisms can be subject to third-party composi- 
tion and work collaboratively. By third-party composition of aspect 
mechanisms we mean a semantical framework in which distinct as- 
pect mechanisms can be assembled with the base mechanism into 
a meaningful multi mechanism without modifying the individual 
mechanisms. The mechanisms are said to be collaborative units 
of composition if the semantics of the composed multi mechanism 
can be derived from the semantics of the mechanisms that comprise 
it. 

More precisely, let B denote the base mechanism for Base. Let 
Mi, . . . , £W n denote the aspect mechanisms for Exti, . . . , Ext™, 
respectively. The aspect mechanism composition problem is to en- 
able the third-party composition of M i , . . . , M n with B into a multi 
mechanism A, in a mannar similar to the assembly of software 
components:' 

• Units of independent production. The aspect mechanisms 
Mi, ... , M n are independently denned. The base mecha- 
nism B is denned independently from Mi, ... , M n . To en- 
able the composition, Mi,. . . , M n rely only on B and have 
an explicit context dependency only on A. 

• Units of composition. The mechanisms are subject to third- 
party composition. The multi mechanism A for the com- 
bined AOP language is constructed (denoted by a EB com- 
binator) by composing the base mechanism with the aspect 
mechanisms without altering them: A = S{B, Mi, ... , M n ) 

• Units of collaboration. The semantics for the composed 
multi mechanism A is the "sum" of the semantics provided 
by all the mechanisms. 

Independence enables third-party development of aspect mecha- 
nisms; composability enables third-party composition of aspect mech- 
anisms; and collaboration enables the desired behavior in the con- 
structed AOP language. 

2 A software component is a unit of composition with contractually 
specified interfaces and explicit context dependencies only. A soft- 
ware component can be dep loyed independently and is subject to 
third-party composition |40|. 



Specifically, our approach enables third-party composition of dy- 
namic aspect mechanisms. We illustrate our solution for expres- 
sion evaluation semantics. We model each aspect mechanism as 
a transformation function that revises the evaluation semantics for 
expressions. 

1.3 Outline 

In the rest of this paper, we demonstrate our solution to the as- 
pect mechanism composition problem concretely through the im- 
plementation of interpreters. The next section motivates the need 
for composing multiple aspect extensions and demonstrates the lack 
of integration support in current aspect mechanisms. Section [3] 
presents a concrete instance of the problem: a base language My- 
Base with two aspect extensions, HisExti and HerExt2. We present 
their syntax and analyze a runnable programming example imple- 
mented in our framework. In Section |4| we present our approach 
for the general case of integrating n aspect mechanisms. In Sec- 
tion [5] we revisit the example shown in Section [3] and formally 
demonstrate our approach by constructing the semantics for My- 
Base, HisExti, and HerExt2. 

2. MOTIVATION 

There is a growing need for the simultaneous use of multiple domain- 
specific aspect extensions. The need steams mainly from the favor- 
able trade-offs that a domain-specific aspect extension can offer 
over a general purpose AOPL: 

• Abstraction. A general purpose AOPL offers low-level ab- 
stractions for covering a wide range of crosscutting concerns. 
Domain specific aspect extensions, in contrast, can offer ab- 
stractions more appropriate for the crosscutting cases in the 
domain at hand, letting the programmer concentrate on the 
problem, rather then on low-level details. 

• Granularity. The granularity of an aspect extension dictates 
all possible concern effect points within an application. Com- 
bining domain-specific aspect extensions allows to overcome 
the fixed granularity limitation of general purpose AOPLs 1 30 1. 

• Expressiveness versus Complexity. The granularity of a general- 
purpose AOPL exposes a non-linear relationship between the 
language expressiveness and complexity. An increase in the 
language granularity would significantly increase the language 
complexity while achieving a relatively small increase in ex- 
pressiveness. Domain specific aspect extensions, in contrast, 
can offer independent diverse ontologies |48 1. 

The need also arises from the sheer abundance of available aspect 
extensions (and their evolving aspect libraries). For the Java pro- 
gramming language alone there are numerous aspect extensions 
that are being used in a variety of commercial and research projects. 
These include: AspectJ (ajc 1121 and abc |4)), AspectWerkz (5), 
COOL (29), JBoss-AOP H), JAsCo |43), Object Teams El, Com- 
posej 1501 . to name just a few. 3 Ability to use these aspect ex- 
tensions together will allow to reuse exiting (and future) aspect li- 
braries written for the different aspect extensions. 

Unfortunately, little support is provided for the integration of dis- 
tinct aspect mechanisms. Each aspect mechanism creates its own 

3 For a complete list of commercial and research aspect extensions 

sec http : / /www .aosd.net /technology/ 
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Listing 1 : A non-synchronized bounded buffer 



Listing 2: Synchronization aspect in COOL 



public class BoundedBuf f er { 

private Object [] buffer; 
private int usedSlots = 0; 
private int writePos = 0; 
private int readPos = 0; 

private static BoundedBuf fer singltn = null; 

public static BoundedBuf fer get Instance ( ) ( 
return singltn; 

} 

public BoundedBuf fer (int capacity) { 
this. buffer = new Ob ject [capacity] ; 
singltn = this; 

} 

public Object remove () { 

if (usedSlots == 0) {return null; } 

Object result = buf f er [ readPos ] ; 

buf f er [ readPos ] = null; 

usedSlots — ; readPos++; 

if (readPos==buf fer . length) readPos=0; 

return result; 



public void add (Object obj) throws Exception 
if (usedSlots==buf fer . length) 

throw new Exception ( "buffer is full"); 
buf fer [writePos ] = obj; 
usedSlots+t; 
writePos++; 

if (wr itePos==buf fer . length) writePos=0; 



unique program representation which often excludes foreign as- 
pects. Consequently, interaction between multiple aspect mecha- 
nisms operating on a single program can produce unexpected or 
incoherent results. 

2.1 Example 

Consider a bounded buffer example implemented in Java (List- 
ing 0. Suppose you have three aspect extensions to Java at your 
disposal: 

• COOL 1 29 1 — a domain-specific aspect extension for express- 
ing coordination of threads; 

• AspectWerkz (o) — a general purpose lightweight AOP frame- 
work for Java; 

• AspectJ — a general purpose aspect extension for Java; 



and two concerns to address, namely, a synchronization concern 
and a tracing concern. 

2.1.1 COOL versus AspectJ 

The synchronization concern can be expressed as a coordinator as- 
pect in COOL (e.g., Listing|2j or alternatively as an aspect in As- 
pectJ (e.g., Listing^. 

The COOL aspect (Listing |2j provides an elegant declarative de- 
scription of the desired synchronization. The mutex exclusion set 



coordinator BoundedBuf fer { 
self ex {add, remove}, 
mutex {add, remove}; 



Listing 3: Synchronization aspect in AspectJ 



public aspect Buf f erSyncAspect { 




private Object remove_thread=null; 




private Object add_thread=null; 




Object around ( ) : 




execution (Ob ject BoundedBuf fer . remove () ) { 


Object this_thread = Thread. curre 


ntThread ( ) ; 


synchronized (this) { 




while ( (remove_thread! =null && 




remove_thread! =this_thread) 


1 1 


(add_thread! =null && 




add_thread! =this_thread) ) 




try {wait ( ) ; 




} catch ( InterruptedException 


e) { } 


remove_thread = this_thread; 




} 

Object result = proceed () ; 




synchronized (this) { 




remove_thread = null; 




notifyAll ( ) ; 




} 

return result; 

} 




void around () throws Exception: 




execution (void BoundedBuf fer . add ( 


Object) ) { 


Object this_thread = Thread. curre 


ntThread ( ) ; 


synchronized (this ) { 




while ( (remove_thread ! =null && 




remove_thread ! =this_thread) 


1 1 


(add_thread! =null && 




add_thread! =this_thread) ) 




try {wait ( ) ; 




} catch (InterruptedException 


e) { } 


add_thread = this_thread; 




} 

try {proceed ( ) ; } 




finally { 




synchronized (this) { 




add_thread = null; 




notifyAll ( ) ; 

} 

} 

} 

} 





( add, remove } specifies that add may not be executed by a thread 
while remove is being executed by a different thread, and vice 
versa. In addition, the self ex exclusion set prohibits different 



threads from simultaneously executing either add or remove 
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The COOL code is expressive, concise, readable, and easy to un- 
derstand. It provides the right abstractions. Studies I33ll46ll32ll47l 
have shown that "participants could look at COOL code and under- 
stand its effect without having to analyze vast parts of the rest of 
the code", and that "COOL as a synchronization aspect language 
eased the debugging of multi-threaded programs, compared to the 



4 However, the same thread is not prohibited from entering both 

add and remove. 
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Listing 4: Logger aspect in AspectWerkz 



/** @Aspect("perJVM") */ 
public class AWLogger { 

/**@ Before call( * *.*(.. ))&&!cflow(within(AWLogger))*/ 

public void log ( JoinPoint jp) { 

System. out . print In ( "AW: "+ jp . get Signature ( ) 



Listing 5: Buffer Logger 



public aspect BufferLogger { 

pointcut toLogO : 

call(* *.*(..)) && ! cf low (within (Buff erLogger) 



bef ore ( ) : toLogO { 

log ( "ENTER", this JoinPoint) ; 

} 

after ( ) returning: toLogO ( 
log ( "EXIT" f this JoinPoint) ; 

} 

after () throwing: toLogO { 
log ( "THROW" r this JoinPoint) ; 

} 

protected void log (String aType, JoinPoint jp) { 
BoundedBuf f er buf =BoundedBuf f er . getlnstance ( ) ; 
if (buf==null) return; 

try {buf . add ( jp) ; } catch (Exception e) ( 
System. out . println (e . getMessage ( ) ) ; 



} 



ability to debug the same program written in Java" 1451 . 

While it is possible to express the same concern in AspectJ, the 
code will be much longer. In comparison to the COOL code, the 
AspectJ implementation (Listing|3j requires 10 times more lines of 
code. It is also harder to explain. The aspect implements a monitor 
using two condition variables remove_thread and add_thread. 
Using two pieces of around execution advice, the aspect obtains 
locks (remove_thread and add_thread) for the duration of exe- 
cuting proceed (execution of remove and add, respectively). This 
guarentees that no more than one thread operates on the buffer at 
a time. If remove_thread or add_thread are locked by some 
other thread, the advice waits. When the thread has a lock, it runs 
proceed and afterwards releases the lock by signaling not i f yAl 1 ( ) , 
which in turn wakes up other waiting threads. 

2.7.2 AspectWerkz + AspectJ 

Semantically, the underlying mechanisms of AspectWerkz and As- 
pectJ are essentially equivalent. Yet, their syntactical differences 
present programmers with a desired choice of alternatives. Re- 
cently is was announced that AspectWerkz has joined the AspectJ 
project to bring the key features of AspectWerkz to the AspectJ 5 
platform (7J. This merger will allow aspects like those in Listing[4] 
and Listing[3]to run side by side. 

Listing |4] is a simple tracing aspect in AspectWerkz. The code 
is plain Java. The annotation @Aspect ( "per JVM") specifies that 
the AWLogger class is actually a singleton aspect. The annotation 



@Before call(* *.*(..)) && ! cf low (within (AWLogger ) ) 
specifies that the log method is to be called for every method call 
not in the dynamic control flow of methods in AWLogger. 

Listing |5]is an auditing aspect in AspectJ. The toLogO pointcut 
specifies that every method call should be logged. The before, 
after ( ) returning, and after ( ) throwing advice add log mes- 
sages to the buffer. 

Arguably, if AspectWerkz and AspectJ were designed to be com- 
posable third-party aspect mechanisms, building AspectJ 5 would 
have been much easier. Moreover, third-party composition of as- 
pect mechanisms would have made other domain specific combina- 
tions possible, like combining COOL with AspectWerkz and Java. 

2.2 Lack of Integration Support 

Unfortunately, current aspect mechanisms fail to compose correctly. 
We demonstrate this failure on the bounded buffer example for two 
commonly used approaches: 

• Translation. Aspect programs in different aspect extensions 
can be translated to a common target aspect extension. 

• Instrumentation. Aspect mechanisms can be implemented by 
means of program instrumentation. Such multiple indepen- 
dent aspect mechanisms can be trivially composed by pass- 
ing the output of one aspect mechanism as the input to an- 
other aspect mechanism. 

2.2.1 No Behavior-Preserving Translation 
The translation approach requires the expressiveness of the target 
aspect extension to support arbitrary granularity. Even when gran- 
ularity does not pose a problem, a translation from one aspect lan- 
guage to another will not generally preserve the behavior of the 
source aspect program in the presence of other aspects. Consider 
the synchronization concern implementation in COOL (Listing|2j- 
Translating it to AspectJ (Listing[3j results in an aspect that seems 
to be a correct substitution for the COOL coordination aspect, but 
in the presence of the Logger aspect (Listing[5J is actually not. 

A property of the COOL synchronization concern is transparency 
with respect to the AspectJ logging concerns. There should not 
be any interference between the two. The COOL aspect does not 
contain any join points that should be visible to the AspectJ mech- 
anism. This property is not preserved in the translation. Calls to 
wait (Listing|3] lines 13 and 33) and notifyAll (Listing|5| lines 
20 and 41), which do not exist in the COOL code, will nonetheless 
be unexpectedly reflected by the logger. 5 

Worse yet, the unexpected join points in the target program may 
break existing invariants, resulting in our case in a deadlock. An 
implicit invariant of the COOL aspect is that if both add and remove 
are not currently executing by some other thread, then the thread 
can enter and execute them. The AspectJ synchronization aspect, 
however, violates this invariant. Assume that two threads concur- 
rently access the buffer. The first thread acquires the lock, while the 
second invokes wait on the Buf f erSyncAspect object. However, 
before wait is invoked, the Buf f erLogger aspect calls BoundedBuf fer . add 
(Listing|5| line 19). The latter call causes the second thread to enter 
the guarded code again and trigger a second call to wait. 6 Since 

5 Note that calls to wait and notifyAll cannot be avoided. 
6 Assuming that the first thread still owns the lock. 
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the second wait call is in the cf low of the logger, it is not advised, 
and the thread finally suspends. When the first thread releases the 
lock, the second thread wakes up after the second wait. It acquires 
the lock, completes the advice execution, releases the lock, and pro- 
ceeds to the first wait invocation. At this point, the buffer is not 
locked; the second thread waits on the Buf f erSyncAspect object 
monitor; and if no other thread ever accesses the buffer, the second 
thread waits for ever — deadlock! 

2.2.2 No Correct Order for Sequential Processing 
One would expect the two aspects written in AspectWerkz (List- 
ingEJ and AspectJ (Listing|5j to interact as if they were two aspects 
written in a single aspect extension (e.g., the future AspectJ 5 plat- 
form). On the one hand, the AspectJ logger should log all method 
calls within the AWLogger aspect. On the other hand, the As- 
pectWerkz logger should log all method calls within Buf f erLogger, 
(And both should log all method calls in the base program as well.) 

However, applying the AspectJ and AspectWerkz instrumentation 
mechanisms sequentially, in any order, produces an unexpected re- 
sult. The mechanism that is run first may not be able to interpret the 
second extension's aspect program. Specifically, the AspectWerkz 
mechanism does not understand AspectJ's syntax. It can be applied 
to the bounded buffer code but not to the Buf ferLogger aspect. 
Thus, when AspectWerkz is run first, some expected log messages 
will be missing. 

The mechanism that is run last logs method calls that are not sup- 
posed to be logged. For example, when AspectWerkz is run sec- 
ond, the following unexpected log message is generated by the 
AWLogger aspect: 

AW: public void Buf ferLogger . 

a j c$af terReturning$Buf ferLogger $2 $balf bd8a ( 
org . aspect j . lang . JoinPoint ) 



3. PROBLEM INSTANCE 

We now return to MyBase, HisExti, and HerExt2 in order to an- 
alyze the problem and illustrate our approach concretely. After a 
brief introduction to the syntax, we informally explain MyBase, 
HisExti, and HerExt2 through a programming example. The code 
fragments are actual running code in our implementation, and their 
semantics is formally presented in Section|5| 

3.1 Syntax 

3.1.1 MyBase Syntax 

The syntax of MyBase is given in FigureQ MyBase is a procedu- 
ral language. Procedures are mutually-recursive with call-by-value 
semantics. The set of procedures is immutable at run-time. Ex- 
pressed values are either booleans or numbers (but not procedures). 
The execution of a program starts by evaluating the body of a pro- 
cedure named main. 

3.1.2 HisExti Syntax 

The syntax for HisExti is given in Figure|2| HisExti is a simple 
AspectJ-like aspect extension to MyBase. HisExti allows one to 
impose advice around procedure calls and procedure executions. 
Advice code is declared in a manner similar to procedures. Like in 
AspectJ, the set of advice is immutable at run-time. Each advice 
has two parts: a pointcut designator and an advice body expres- 
sion. Atomic pointcuts are pcall-pcd, pexecution-pcd, 



cf low-pcd, and args-pcd. The and-pcd and or-pod al- 
lows one to combine several pointcuts under conjunction and dis- 
junction, respectively. Unlike AspectJ, around is the only advice 
kind in HisExti. There is no support for patterns in pointcut des- 
ignators. HisExti introduces a new proceed-exp expression, 
which is valid only within an HisExti advice body expression. 

3.1.3 HerExt 2 Syntax 

HerExt2 allows one to declare a set of exception handlers in My- 
Base for catching and handling division by zero before an excep- 
tion occurs. Advice code in HerExt2 specifies an exception handler 
expression. A guard clause allows one to specify a dynamic scope 
for the handler. HerExt2 introduces a new expression, namely 
raise-exp, which is allowed within a handler. It passes the 
exception handling to the next handler (in a manner, similar to 
proceed-exp of HisExti). The syntax of the language is given 
in Figure 

The semantics for HerExt2 is straightforward. Whenever the sec- 
ond argument to the division primitive evaluates to zero, the advice 
handler (if one exits) is invoked. The handler is evaluated and the 
result value substitutes the offending zero in the second argument 
to the division primitive, and the program execution resumes. 

Listing [8] shows an aspect we can write in HerExt2. This aspect 
resumes the execution with the value of Precision ( 1 ) whenever 
the second argument of a division primitive evaluates to within 
the control flow of the SQRT procedure. 

3.2 A Programming Example 

The semantics for the base procedural language MyBase and the 
aspect extensions HisExti and HerExt2 are implemented as inter- 
preters 1191 . The example presented here is a simple executable 
arithmetic program in MyBase for computing the square root of a 
given number. While simple, the example is representative in terms 
of illustrating the complexity of achieving collaboration among as- 
pect extensions, and its semantics serves as a proof of concept. 

The procedure SQRT in Listing[6]implements in MyBase a simple 
approximation algorithm using a sequence generated by a recur- 
rence relation: 

ao=approximation ; repeat a n =/(a n _i) until precise 

By default, it sets ao = 0, and calls Sqrtlter to generate the 
recurrence sequence: 

dn — CLn-1 + 6 

until (a n ) 2 > x. The procedure Improve generates the next ele- 
ment in the sequence; IsPreciseEnough? checks the termina- 
tion condition; and the value e = e(x) is computed as a function of 
x by the procedure Precision. 

The resulted computation of s/x is inaccurate and extremely ineffi- 
cient. However, it serves our purpose well. We will non-intrusively 
improve its efficiency using an aspect in HisExti. We will correct 
its behavior for the singular point x — using HerExt2. 

The code in Listing written in HisExti, advises the base code 
for drastically improving its efficiency and accuracy. Four pieces 
of advice are used. The first around advice (lines I202ll204t inter- 
cepts executions of the procedure Improve and instead applies 
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Program : 


:= Declaration 


Program 


Declaration : 


:= "program" "{" Procedure* "}" 


Declaration 


Procedure : 


:= "procedure" PName "(" Id* ")" Exps 


Procedure 


Exps : 


:= lit-exp | true-exp | false-exp 

var-exp | app-exp | begin-exp | if-exp | 






assign-exp | let-exp | primapp-exp 


Expressions 


lit-exp : 


:= Number 


Numbers 


true-exp : 


:= "true" 


True 


false-exp : 


:= "false" 


False 


var-exp : 


:= Id 


Id meaning 


app-exp : 


:= "call" PName "(" Exps* ")" 


Procedure call 


begin-exp : 


._ "|" g X pg ( "." E X pg y 


Block 


if— exp : 


:= if Exps then Exps else Exps 


Conditional 


assign-exp : 


:= "set" Id "=" Exps 


Assignment 


let-exp : 


:= "let" ( Id "=" Exps )* "in" Exps 


Let 


primapp-exp : 


:= Prim "(" Exps* ")" 


Primitive application 


Prim : 


. = « + >, | ...» , ..*„ | « r 


Primitives 


Id 




Identifier 


PName 




Procedure name 


Number 




Numbers 



Figure 1: MyBase syntax 



AOPl-Program : 


:= AOPl-Declaration 


His Ext i program 


AOPl-Declaration : 


:= "aopl" "{" Advice* "}" 


HisExti declaration 


Advice : 


:= "around" ":" Pointcut Expsi 


Advice 


Pointcut : 


:= call-pcd | exec-pcd | cflow-pcd | 






args-pcd | and-pcd | or-pcd 


Pointcut designators 


call-pcd : 


:= "pcall" "(" PName ")" 


Procedure call pcd 


exec-pcd : 


:= "pexecution" "(" PName ")" 


Procedure execution pcd 


cflow-pcd : 


:= "cflow" "(" PName ")" 


Control flow pcd 


args-pcd : 


:= "args" "(" Id* ")" 


Argument pcd 


and-pcd : 


:= "and" "(" Pointcut* ")" 


Conjunction pcd 


or-pcd : 


:= "or" "(" Pointcut* ")" 


Disjunction pcd 


Expsx : 


:= Exps ] proceed-exp 


Advice expressions 


proceed-exp : 


:= "proceed" 


Proceed exp 



Figure 2: HisExti syntax 



A0P2-Program : 


:= A0P2-Declaration 


HerExt2 program 


A0P2-Declaration : 


:= "aop2" "{" Handler* "}" 


HerExt2 declaration 


Handler : 


:= "guard.cflow" PName "resume.with" Exps 2 


Handlers 


Exps 2 : 


:= Exps ] raise-exp 


Handler expressions 


raise-exp : 


:= "raise" 


Raise expressions 



Figure 3: HerExt2 syntax 
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Listing 6: A naive program in MyBase for computing ^fx 



program { 
procedure SQRT (radicand) { 

call Sqrtlter ( , radicand, call Precision (radicand 
) ) 

} 

procedure Sqrtlter (approximation, radicand, 
precision) { 

let 

bid = call Improve (approximation, radicand, 
precision) 

in 

if call IsPreciseEnough? (bid, radicand) 
then bid 

else call Sqrtlter (bid, radicand, precision) 

} 

procedure Improve (approximation, radicand, 
precision) { 
+ (approximation, precision) 

} 

procedure Precision (x) {1} 
procedure IsPreciseEnough? ( root , square ) ( 
It? (square, call Square (root) ) 

} 

procedure Square (x) (*(x,x)} 

procedure Abs (x) {if lt?(x,0) then -(0,x) else x} 
procedure main ( ) {call SQRT (5)} 

} 



Listing 7: Advice in HisExti for using Newton's method 



aopl { 

around: and (pexecution (Improve) args (an, x, epsilon) ) { 
/ (+ (an, / (x,an) ) , 2) 

} 

around: and (pexecution (IsPreciseEnough?) args(root,x) 

) I 

It? (call Abs (-(x, call Square ( root ))), call 
Precision (x) ) 

} 

around : pcall (Precision) { 
/ (proceed, 1000) 



Listing 8: Advice in HerExt2 for preventing an exception 



3oi aop2 { guard.cflow SQRT resume.with call Precision (1) } 



(num-val 161/72) 

meaning ^ = 2.2361111 = 75.0001929 = y/E. 

The improved program works well for all non-negative inputs to 
SQRT, except for when the radicand is 0. In this case, Improve 
is called with the first argument a n set to 0. The execution of 
Improve triggers the advice around Improve execution which 
divides x by a n . Since the value of a n is an exception occurs. 

3.3 Third-party Composition 

The main point of this example is that HisExti and HerExt2 are 
subject to third-part composition with MyBase and work collabo- 
ratively: 

• Units of independent production. HisExti and HerExt 2 
are independently constructed. 

• Units of composition. MyBase, HisExti, and HerExt2 are 
units of composition. MyBase can be used by itself (running 
only Listing [6). MyBase can be used with HisExti alone 
(omitting Listing [SJ. MyBase can be used with HerExt2 
alone (omitting Listing^. MyBase can be used with both 
HisExti and HerExt2. 

• Units of collaboration. When HisExti and HerExt2 are 
both used they collaborate. In the absence of HerExt2, call- 
ing 

call SQRT(0) 
results in 

Error in / : undefined for . 

However, when HerExt2 with the advice code in Listing [5] 
are present, the correct value is returned. The violating 
primitive division application is introduced by the advice of 
HisExti, yet intercepted by the advice of HerExt2. This de- 
sired behavior is non-trivial because HisExti was constructed 
without any prior knowledge of HerExt2. 

3.4 Analysis 

In order to achieve a correct collaboration: 



Newton's method: 



fln + l — 




The second around advice (Iines l205ll207t intercepts IsPreciseEn 
executions and checks instead whether or not |(an) 2 — x\ < e 
where e = — Lj is set in the third around advice ( lines I208U21 1> . 
The successive approximations now converge quadratically. 

Running main and calling 
call SQRT (5) 



• The aspectual effect of all extension programs needs to be 
exposed to all the collaborating aspect mechanisms. 

• Each individual aspect mechanism must hide its implemen- 
tation from other aspect mechanisms. 

ugh? 

3.4.1 Exposure of Aspectual Effect 
In the context of multiple distinct aspect mechanisms, certain ele- 
ments of the aspect program should be exposed to all collaborating 
aspect mechanisms. We call these elements the aspectual effect. 
The aspectual effect of an aspect program generally specifies the 
implementation of a crosscutting concern. We assume that the as- 
pectual effect is expressed in the base language. 
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7 The result shown is the actual value returned by the Scheme 1 36 1 
implementation. 



In our example, the aspectual effect of an aspect 1 G HisExti is 
specified by advice-body expressions; the aspectual effect of an 
aspect 2 G HerExt2 is specified by handler expressions. When His- 
Exti and HerExt2 are composed together, their mechanisms must 
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reflect each other's effect. Specifically, HisExti aspects must be 
able to advise procedure calls made from the HerExt2 handler ex- 
pressions; and HerExt2 handlers must be able to intercept excep- 
tions introduced by the HisExti pieces of advice. 

3.4.2 Hiding of Mechanism Implementation 
An aspect extension extends the base language with new function- 
ality. For example, HisExti adds advice binding, and HerExt2 adds 
exception handling to the base language. An aspect mechanism 
that implements the new functionality must hide its internal opera- 
tions from the other aspect mechanisms. In our example, pointcut 
matching and advice selection operations of the HisExti mecha- 
nism must be hidden from the HerExt2 mechanism. Conversely, 
testing whether the second division primitive argument evaluates 
to zero and the exception handler selection of HerExt2 should be 
invisible to the HisExti mechanism. 

4. OUR APPROACH 

Now that we have illustrated a desired behavior, we explain our 
solution to the aspect mechanism composition problem in general. 

4.1 Aspect Mechanisms as Mixins 

The primary idea is to view an aspect mechanism that extends a 
base mechanism as a mixin 1131 that is applied to the base mech- 
anism description. A description of a mechanism is an encoding 
of its implementation (e.g., a configuration of an abstract machine 
or its semantics). An aspect mixin mechanism transforms some 
of the base mechanism description and introduces some additional 
description. 8 

By keeping a clean separation between the descriptions of the base 
and aspect mechanisms, the aspect mixin mechanism may be com- 
posed with other mechanisms that extend the same base language. 
The particular composition strategy may differ. In the next section 
we show a concete instance of this general approach. 

4.2 Solution Instance 

We illustrate the approach specifically for expression evaluation se- 
mantics. To build a multi mechanism, the composed aspect mech- 
anisms are organized in a chain-of-responsibility |20|, pipe-and- 
filter architecture 1371 (Figure |4j. Each aspect mechanism per- 
forms some part of the evaluation and forwards other parts of the 
evaluation to the next mechanism using delegation semantics (3) 
("super"-like calls). If an expression is delegated by all mecha- 
nisms then it is eventually evaluated in B. All the mechanisms 
defer to A for the evaluation of recursive and other "self-calls. 




Figure 4: Mixing-like composition of aspect mechanisms 



sidered a collaborative unit provided it properly hides, delegates, or 
exposes the evaluation. 

Notation. 

The following notations are pertinent. We express functions in Cur- 
ried form. The Curried function definition 

fn pati pat2 . . . pat n => exp 

is the same as the lambda expression A pat\ .A pat2 .... A pat„.exp. 
Correspondingly, we write a list of function arguments with no 
parentheses or commas to express a function application that takes 
the first argument as its single parameter, which could be a tuple, 
constructs and returns a new function, which then takes the next 
argument as its single parameter, and so on. In function types, '— 
associates to the right. 

We use the form (id as pat) in a formal argument to bind an iden- 
tifier id to a value and match the value with a pattern pat. Vari- 
ables in the pattern bind to their corresponding values. We use 
val pat = val to split apart a value. The symbol '_' stands for an 
anonymous variable (don't care). The symbol o denotes an empty 
mapping and [] denotes an empty list. 



A subtlety in designing a collaborative aspect mechanism is decid- 
ing what to hide, what to delegate, and what to expose. A mech- 
anism may hide its effect by directly reducing an expression. A 
mechanism may refine the next mechanism's semantics by delegat- 
ing the evaluation. A mechanism may expose its effect by evaluat- 
ing expressions in A. The latter allows what is known as "weav- 
ing". The exposed expressions are then evaluated collaboratively 
by all the mechanisms. As a result, an effect of an aspect mecha- 
nism is made visible to all the other mechanisms. Hence, the mech- 
anisms reflect one another's effect. Overall, a mechanism is con- 

8 We generally assume that granularity requirements of an aspect 
mechanism can always be satisfied by either taking the most fine- 
grained description form (e.g., small-step operational semantics), 
or refining (e.g., annotating) the current description. 



4. 2. 1 Overall Semantics 

Let «4[ea;p] denote the meaning of an AOP expression exp. Our 
goal is to be able to build the multi mechanism A by composing 
the base mechanism B and the mutually independent aspect mech- 
anisms 9fi, . . . , <M n . 

Base introduces a domain Exp of base expressions. In addition, 
each of the extensions Exti , Ext2, . . . , Ext n may introduce its own 
respective domain of additional expressions Expj, Exp 2 , . . . , Exp n . 9 
The domain of AOP expressions Exp 4 is hence a union of pair- 
wise disjointed expression domains defined by: 

Exp A = Exp + Expj + Exp 2 H + Exp n 

9 We assume that Exp^ n Exp^ = <f> for all < i < j < n. 
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The additional expressions are concern integration instructions for 
the respective aspect mechanism. A concern implementation, on 
the other hand, is expressed using base language expressions in 
Exp only. 

EXAMPLE 1. HisExti introduces a proceed-exp and HerExt2 
a raise-exp to specify nesting of advice and handler executions, 
respectively. An aspect 1 G HisExti in implemented in Exp + 
{proceed-exp} and an aspect 2 G HerExt2 in Exp + {raise-exp}. 

We use the term AOP configuration to denote the state of a multi 
mechanism A. An AOP configuration cfg G Cfg 4 is a vector of 
configurations of the composed mechanisms: 



Cfg A = Cfg x Cf gl x Cfg 2 



xCfg, 



where Cfg denotes a domain of the base mechanism states, and 
Cfgj, 1 < i < n, denotes a domain of the aspect mechanism Mi 
states. 

EXAMPLE 2. Informally, a MyBase mechanism configuration 
comprises a procedure environment, a variable environment, and a 
store. A HisExti mechanism configuration comprises a list of ad- 
vice, a "current" join point, and a " current" proceed computation. 

The effect of evaluating an expression exp G Exp A is to change 
the AOP configuration. The meaning of an expression exp G Exp A , 
denoted ^l[esp], is defined to be a partial function on configura- 
tions: 



A : Exp A - (Cfg A - Cfg A ) 
We denote by ContA the set of partial functions on Cfg 4 . 

4.2.2 Design Guidelines for the Base Mechanism 
B provides semantics for expressions in Base. The meaning of an 
expression exp G Exp in Base, denoted S[ea;p], is expected to 
be defined as: 

B : Exp — > Cont.4 
The semantical function B should adhere to the following design 
principles: 

• All sub-reductions within a S-reduction are reduced by call- 
ing A instead of B. 

• B only accesses and updates the head Cfg -element of the 
cfg G Cfg A configuration, and carries the tail through the 
computation. 

Note that the fact that B is defined in terms of Cfg A does not mean 
that A or n are known at the time of writing B. At the time of 
writing the base mechanism, A is assumed to be: 



A\exp\ = 



Blexpl 



1 



exp G Exp () 
otherwise 



where _L stands for "undefined". Let B : Exp — > Cfg — > Cfg 
denote the evaluation semantics for Base with its standard signa- 
ture. B is extended to have the signature of B (without knowing n) 
as follows: Vexp G Exp ,Vc/g = cfg ::cfg* G Cfg A : 



B\exp\ cfg 



tfg'o -cfg* H ex v\ c f9a = c fg'o 

± B\exp\ cfg = J_ 



4.2.3 Design Guidelines for an Aspect Mechanism 
We construct the aspect mechanism <Wj for an aspect extension Ext; 
as the override combination 10 of a semantics transformer T", and a 
semantical function £c 

valstfj = fn eval => (T; eval) © £i 

Semantics for the Ext; 's newly introduced expression domain Exp ; 
is defined by: 

Si : Exp ; — > Cont.4 

The introduction of Ext; into the base language also requires a 
change to the evaluation semantics for a non-empty" subset of the 
existing base language expressions Exp, 1 ) C Exp . We define this 
part of the semantics for Ext; as a language semantics transformer: 



Ti : (Exp — > Cont.4) — » (Expg — > ContA) 

The semantics transformer Ti should adhere to the following de- 
sign principles: 

• Ti defines the semantics for Ext; and nothing more. Let B' 
denote a semantical function with the same signature as B or 
an extended signature. 12 Ti (B') delegates the evaluation to 
B' whenever the base language semantics is required. 

• Ti(B') accesses only the Cfg - and Cfg 4 -elements in a 
cfg G Cfg A configuration, while the rest are carried through 
the computation. 

Note that allowing the aspect mechanism access to the Cfg ele- 
ment is needed for modeling interesting cases of aspect mechanism 
interactions. 

4. 2.4 Third-party Construction of an AOP Language 
Let B denote the Base mechanism, and let {ki}" =1 be an ordered 
index set. Let aik 1 , ■ ■ ■ , <Mk n denote the aspect mechanisms for the 
aspect extensions Extfcj , . . . , Extfc„, respectively. 

We construct the multi mechanism A as the composition: 

A=m{B,M kl ,...,M hn ) 

where the composition semantics for EB is defined as following. The 
meaning of exp G Exp A , denoted ^4„[ea;p] cfg, is given by the 
recurrence relation: 

Ao = B 

•A-n — ■An — 1 n — 1 ) 

By construction, 

A„ : (Exp + Exp fcl H h Exp fcn ) Cont4 

is of the right signature and obeys the composition principle. To il- 
lustrate the construction, we conclude by elaborating the first three 
instances: 



For two partial functions g and h, their override combination g(Bh 
(h overrides g), is defined by: 

(<? © h){x) = def I oJLraiTe^ 
"W.l.o.g., assume Expp / <j>. 

12 An extended B may have a signature B' : Exp[, — ► Cfg A , where 
Exp; D Exp . 
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Figure 5: Expression Domains for 1 = 2 

• For I = 0, we have that Exp A = Exp , and the meaning 
of exp G Exp A is the same as the meaning of exp in Base: 

A : Exp — ► ContA 

^[ea;?] cfg = 23 [exp] cfg 

• For I = 1 and the singleton index set {i} for some 1 < i < 
n, we have that Exp A = Exp + Exp; . The meaning of 
exp G Exp A is 

W 



A 

We construct 



(Exp + Expj) — ► ContA 



.4 W =B©(T,B)® & 



.4 w [exp] eft = 



(T, B)lexp\cfg 
B\exp\ cfg 



• For I = 2 and the ordered index set {i,j} for some 1 < 
hj < we have that Exp A = Exp n + Exp, ; + Exp^ 
(Figure[3J. The meaning of exp G Exp A is 

A {i ' j} : (Exp + Exp 4 + Exp,) -> ContA 



We construct: 



A {i,n = A ii} ®(T j A {i} )®£j 



A {i ' i} lexp\ 



£j\exp\ 

Silexpj 

(Tj B)\exp\ 

(TiB)lexpj 

(T, (B © (Ti B)))\exp\ 

B\exp\ 



annotated-exp 


= procbody-exp \procarg-exp \primarg-exp \ 




assignrhs-exp \block-exp \letbody-exp \ 




letrhs-exp \ if-exp \ then-exp \else-exp 


procbody-exp 


= Exp x PNm 


Procedure body 


procarg-exp 


= Exp x (PNm x Var) 


Procedure arg 


primarg-exp 


= Exp X (Prim X Int) 


Primitive arg 


assignrhs-exp 


= Exp x Var 


Assignment RHS 


block-exp 


= Exp x Int 


Block element 


letbody-exp 


= Exp x Var* 


Let body 


letrhs-exp 


= Exp x (Var x Int) 


Let env RHS 


if-exp 


= Exp x {if} 


If exp 


then-exp 


= Exp x {then} 


Then exp 


else-exp 


= Exp x {else} 


Else exp 


Figure 6: Annotated Expressions 


app-exp 


= PNm x procarg-exp* 


Procedure call 


begin-exp 


= block-exp* 


Block 


cond-exp 


= if-exp X then-exp X else-exp 


Conditional exp 


assign-exp 


= Var x assignrhs-exp 


Assignment 


let-exp 


= Var* x letrhs-exp* x 






letbody-exp 


Let 


primapp-exp 


= Prim X primarg-exp* 


Primitive app 



Figure 7: Complex Expressions 





cfdo G Cf §0 


= Envp x Env v x 


Base 






Store 


configuration 




envy € Envy 


= Var — > Loc 


Variable envs 


exp e Exp^ 


sto G Store 


= Loc -> Val 


Value Stores 


exp £ Expg 


envp G Envp 


= PNm — > Proc 


Procedure envs 


otherwise 


6 G Proc 


= Var* x procbody-exp 


Procedures 



exp G Expj 

exp G Exp, ; 

exp G Expjj — Expo 

exp G ExpJ — ExpJ 

exp G Expp n Exp/, 

otherwise 



5. IMPLEMENTATION 

As a proof of concept we have implemented My Base, HisExti, and 
HerExt 2 for the example presented in Section^ This section pro- 
vides the implementation details more formally to the so-inclined 
reader. 

5.1 Base Mechanism Implementation 

The domain Exp 4 of AOP expressions includes My Base, His- 
Exti, and HerExt2 expressions. We define Exp by extending the 
expression set Exps with a set of annotated expressions: 

Exp = Exps + annotated-exp 



Figure 8: MyBase domains 

Annotated expressions (Figure |6j extend the interface of the base 
mechanism to satisfy granularity needs of the HisExti and HerExt2 
mechanisms. A complex expression (Figure^ includes annotated 
expressions as subexpressions. 

The base configuration domain Cfg u consist of a procedure en- 
vironment domain Envp , a variable environment domain Envv , 
and a value store domain Store (Figure|8j. A procedure is repre- 
sented as a closure that contains argument names and a procedure 
body expression. The other definitions are omitted. 

The evaluation semantics B (Figure |9j for Exp () expressions sat- 
isfies the design principles for the base mechanisms: (1) all ex- 
pression evaluations in B are exposed to A (highlighted in the 
figure); (2) it accesses and updates only the Cfg -element of the 
configuration; (3) the other configurations are carried through the 
computation. 

5.2 Aspect Mechanism Implementation 

The aspect mechanisms are implemented as mixins to the base 
mechanism (Fieure fTol . The semantics for Exti is specified using 
three constructor functions: 

• build- £i constructs an evaluator for Exp, ; expressions: 
build- Si : Int — > (Exp^ — > ContA) 
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val B : Exp —* ContA 

= fn (lit-exp (num)) (_,_, sto) :: cfg* =£■ 

(o, o, sto [0 i — * (num-val num)]) :: cfg* 
| fn (true-exp (>) (_,_, sto) :: cfg* => 
(o, o, sto [0 i-> (bool-val #t)]) :: c/p* 
fn (f alse-exp (}) (_,_, sto) :: cfg* =>■ 

(o, o, sto[0 i — * (bool-val #f )]) :: cfg* 
fn (app-exp {pname, [expi, . . . , exp n ])) cfg :: cfg* 
let 

val (envp, enw , sto) = c/g 
val (_,.,s(oi)::c/j; = 

.4 expi (enup , enuv , sto):: cfg* 

val (_,_,sto n )::cfg* = 

A exp n (envp, envy , sto n -i) "c/g*_! 
val ([idi , . . . , id n ] , expproc) = envp pname 
val ui = stox 

val w„ = sto n 

val sto n+ i — sto n [h i— > vi], h ^ dom sto n 

val sto 2n = sto 2n -i[l n >-* v„], l n £ dom sto 2n _i 
in 

yl expproc (envp,o[id! i-> Zi, . . . , id„ i-> Z n ], sto 2n ) ::c/g* 
end 
I •■• 

fn (annotated-exp (exp,_)) cfg =>■ .4 ea;p cfg 
Figure 9: MyBase semantical function 



build- Ti constructs the semantics transformer for the Ext^: 

Evalo -^Eval, 1 -, 



B 



#Cfg 



-\-eval(exp) 

#app-exp(pname, [expl, exp n \) 
#procbody-exp(eicpb , pname) 
#primarg-exp(eicp arg , prim, pos) 



is: 





<w 2 


-Cf Sl 


-Cfg 2 


4-eua/(e£Cp) 

#app-exp(pname, [expl, exp^]) 
#procbody-exp(ea;pb , pname) 
— proceed-exp() 


-\-eval(exp) 

#primarg-exp(ea;p aT > g , prim, pos) 
#procbody-exp(ea;pb , pname) 
— raise-Gxp() 



Figure 10: Aspect mechanisms as mixins 



exp G Exp ad „ 


= Exp + Exp x 


Advice exps 


c/Pr € Cf gl 


= Adv* x JP x ContA 


Configuration 


adv G Adv 


= PCD x Ex Pad „ 


Advice 


JP G JP 


= {call, exec} x PNmx 






Var* x Val* x JP + Unit 


Join points 


pcd G PCD 




Pointcuts 


effect G Effect 


= Bnd* x Exp ad „ 


Effects 


fend 6 Bnd 


= Var x Val 


Binding 


Figure 11: HisExti Domains 



build- T ' i : Int — > (Exp — > ContA) — ► (Exp — > ContA) 

build- Mi constructs the aspect mixin mechanism sW j for Exti : 

val build- Mi : Int — > Evalo — > (Exp u + Exp 4 ) — > ContA 
= fn pos eval =>■ (build- Ti pos eval ) © (build- Si pos) 



The Int arguments provides the position of the extension's config- 
uration domain Cfg 4 within Cfg A . 

5.2.1 HisExti Mechanism 

The aspect mechanism Wi transforms the semantics for procedure 
calls and executions, and supplies semantics for Exp x 's new pro- 
ceed expression: 

ExpJ = {app-exp, procbody-exp} 
Expj^ = {proceed-exp} 

A configuration cfg 1 G Cfgj for HisExti (Figure fTTl comprises a 
set of advice, a "current" join point, and a "current" proceed contin- 
uation. An advice adv £ Adv is derived directly from HisExti 's 
syntax. A join point jp G JP is an abstraction of the procedure 
call stack. It stores the name, formal and actual arguments of a cor- 
responding procedure. The third element provides a meaning for 
proceed expressions. The effect and binding domains are internal 
to the mechanism. An effect carries a set of bindings and an advice 



local 

val app-ejf : Int — ► Effect* — > Evalo — * Evalo 
= fn _ [] eval exp cfg => eval exp cfg 

| fni (bnd* dv ,exp adv ):: effect* eval => 
fn exp (envp, envy , sto) :: cfg* => 
let 

val (adv* ,jp,procd) = ni(cfg*) 
val procd' : ContA 
= &(_,_, sto'):: cfg*'^ 

app-eff i effect* eval exp {envp, envy , sto ) :: cfg* 
val (envy' , sto') = build-adv-env bnd* a< i v sto 
val cfg*' = cfg*[i h-> (adv* , jp, procd')] 
val cfg' :: cfg*" = A exp a dv (envp , envy' , sto') :: cfg*' 
in 

cfg' "-cfg*"[i 
end 



(adv* , jp, procd)] 

val build- T i : Int — » Evalo — > Evalo 

= fn i eval exp cfg :: cfg* => 
let 

val (adv* ,jp enc , procd) = -Ki(cfg*) 
val jp = build-jp exp jp enc cfg 
val effect* = match- jp jp adv* 
val cfg*' = cfg*[i h-> (adv* , jp , procd)] 
val cfg' :: cfg*" = app-eff i effect* eval exp cfg :: cfg*' 
in 

cfg o"- cfg* "[i 
end 
end 



(adv* , jpenc, procd)] 



Figure 12: build- T i semantics 
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val build- E\ : Int — ► Exp : — » Contyt 

= f n i (proceed-exp (}) (c/<? as _ :: c/g*) =>■ 
let 

va ' {_,_,P r ocd) = in(cfg*) 
in 

procd cfg 
end 



Figure 13: build- £i semantics 

body expression. The bindings provide an appropriate variable en- 
vironment for evaluating the advice body expression. 

The interesting part of the aspect mechanism 94.\ implementation 
is given by build-Ti (Figure fT2l . build-Ti defines a transformer 
of the semantics for procedure calls and procedure executions. The 
new semantics creates a join point, matches it against an advice 
list, and applies selected advice effects in app-eff. The function 
ensures that the mechanism's configuration properly reflects a "cur- 
rent" join point by setting it before and after an effect application. 

app-eff has two general behaviors. If the effect list is empty then 
the expression evaluation is delegated . Otherwise, the function 
exposes the effect by evaluating the advice expression exp a dv in 
A. expadv is evaluated in a properly constructed variable environ- 
ment envvadv and a proceed continuation procd' . 

app-eff ensures that the mechanism configuration always stores a 
proper proceed continuation in the same manner as build- T\ re- 
flects a "current" join point. This makes build- Si straightforward 
(Figure fT3l . The meaning of a proceed-exp expression is given 
by the proceed continuation obtained from the configuration. The 
continuation then runs app-eff on the rest of the effect list. In other 
words, a proceed-exp expression either evaluates the next ad- 
vice in A or delegates the evaluation to eval if there is no advice 
left. 

Due to space considerations, we omit the HisExti functions match-jp, 
build-jp and build-adv-env, which do not affect the mechanism com- 
position semantics. 

5.2.2 HerExt 2 Mechanism 

The 3^2 mechanism for HerExt2 transforms the semantics for a 
primitive argument and procedure execution expressions, and sup- 
plies semantics for Exp 2 's new raise expression: 

ExPq = {primarg-exp,procbody-exp} 
Exp 2 = {raise-exp} 



A configuration cfg 2 <E Cfg 2 (Figure ll4l stores a list of handlers, a 
stack of currently executing procedures (a list of procedure names), 



exp € Exp hnd 


= Exp + Exp 2 


Handler exps 


cfg 3 e Cf g2 


= Handler* x PNm* x 






Cont.4 


Configuration 


find £ Handler 


= PNm x Exp hnd 


Handlers 


Figure 14: HerExt2 Domains 



local 

val app-handler : Int — > Exp^ nd — > Cont.4 
= fn_ Q cfg cfg 

fn i exp ::exp* {envp , _, sto) :: cfg* => 
let 

val (hnd* , stack, raise) = Ki(cfg') 
val v — sto 
val raise : Cont.4 
= fn (envp , envy , sto) :: cfg* =>■ 
app-handler exp* (envp , envy , sto [0 1— > v]) :: cfg* 
val cfg*' = cfg*[i t—> {hnd* , stack, raise'}] 

val cfg' :: cfg*" = A exp {envp , o, sto) :: cfg*' 
in 

cfg' \: cfg*"[i >—> {hnd* , stack, raise)] 
end 

in 

val build- T 2 ■ Int — > Evalo — > Evalo 

= f h i eval (primarg-exp {exp arg ,prim,pos) as exp) cfg => 
let 

val {envp, envy,_) ::_ = cfg 
val (cfg' as (_,_, sto) :: cfg*) = eval exp cfg 
in 

if (sto = (mim-val 0) A prim — "/" A pos = 2) 
then 
let 

val (hnd* , stack , _) = TTi(cfg*) 
val exp* hnd = match-handler hnd* stack 
in 

app-handler i exp* hnd (envp , envy , sto) :: cfg* 
end 
else cfg' 
end 

fn i eval (procbody-exp (expt,pname) as exp) cfg Q :: cfg* 
let 

val (hnd* , stack, raise) — Hi(cfg*) 

val cfg*' = cfg*[i 1— > (hnd* ,pname:: stack, raise)] 

val cfg' :: cfg*" = eval exp cfg :: cfg*' 
in 

cfg' :: cfg*"[i 1— > (hnd* , stack, raise)] 
end 

end 



Figure 15: build- T 2 semantics 



and a "current" raise continuation. A handler hnd £ Handler 
is derived from the syntax of HerExt2. It contains a name of a 
guarded procedure and a handler expression. A handler expression 
may contain a raise-exp expression. 

The new semantics for primarg-exp enables the invocation of 
a handler in an exceptional situation when the second argument of 
a division primitive evaluates to zero. In this case, build- T 2 (Fig- 
ure^) selects a list of handler expressions using match-handler 
and invokes them using app-handler . If no exception occurs, the 
original semantics is used. 

The mechanism reflects the execution stack of its configuration by 
transforming the semantics for procbody-exp expressions. The 
new semantics simply pushes the stack before and pops it after ap- 
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val build- £2 : Int — ► Exp 2 — ► Cont.4 

= fn z (raise-exp ()) (c/g as _ :: c/<?*) =>• 
let 

val (_,_, raise) — 7Vi(cfg*) 
in 

raise cfg 
end 



Figure 16: build- £2 semantics 

plying eval . 

app-handler produces a configuration transformer from a list of 
handler expressions. If the list is empty then the transformer is 
the identity function. Otherwise, the configuration is constructed 
by evaluating in A the first handler expression. The function also 
constructs and reflects a raise continuation in the mechanism con- 
figuration. The continuation simply applies app-handler to the rest 
of the handlers. 

The build- £2 function (Figure I Kit is similar to build- E\ . The 
meaning of a raise-exp expression is provided by the raise con- 
tinuation drawn from the configuration. 

Due to space considerations, we omit the match-handler function 
of HerExt2. This function bars no affect on the mechanism com- 
position semantics. 

5.3 Constructing an AOP language 

We construct the semantical function for the composed AOP lan- 
guage as follows: 

A = EB (B, flfi,flf2) 

where 

flWTi = build- Mi 1 

and 

9>(2 = build- M2 2 

The meaning of a program 

p = (base, aspect 1 , aspect 2 ) 
in the composed AOP language is defined as: 

2%1 = -4 exp main (cfg , cfg l7 cfg 2 ) 

such that 

expmain = (app-exp ('main, [] )) 
c fdo —(envp, 0,0} envp = Dofbasej 

c /<7i — (adv* , (}, 0} adv* = Si [aspect -J 

c fd2 — (hnd* , [] ,0) hnd* = 2) 2 [ aspect 2 ] 

6. DISCUSSION AND FUTURE WORK 

Our study of constructing an AOP language with multiple aspect 
extensions opens interesting research questions. 

6.1 Alternative Collaboration Semantics 

The co-existence of multiple aspect extensions raise a question con- 
cerning the desired policy of collaboration. The presented solu- 
tion instance defines the combinator EB operations to "wrap" as- 
pect mechanisms around each other and around the original mean- 
ing. This grants the aspect mechanism with complete control over 



the original meaning and the option to override it. For example, 
the HisExti mechanism might disable the original semantics of 
app-exp and procbody-exp expressions when they are advised with 
no proceed. A mechanism can either delegate the expression eval- 
uation to the next mechanism or evaluate the expression itself. In 
the latter case, the evaluated expression is "filtered" out. We call 
this a composition with wrapping semantics. 

Collaboration with wrapping semantics is sensitive to the order of 
composition. The program example in Listing [5] illustrates a col- 
laboration with wrapping semantics. 

Listing 9: Collaboration semantics in AOP 

1 program {procedure main() { 1 } } 

2 aopl { around () : pexecution (main) {/(1,0)} } 

3 aop2 { guard.cflow main resume.with 2 } 



If the AOP language is constructed as 

A = m (b,m 2 ,mi) 

Mi is applied first and replaces the procbody-exp of main with 
the advice body expression. Consequently, Hi does not observe 
the execution of main in the execution stack and would not guard 
the division. The program would therefore throws a divide-by-zero 
exception. On the other hand, if the language is constructed as 

A= EB (B,3tfi,3tf 2 > 

the exception is caught. 

In wrapping semantics different mechanisms generally reflect dif- 
ferent views of the program execution. Alternatively, one can pro- 
vide a collaboration semantics where all the mechanisms share a 
unique program view. This can be achieved by decoupling the reifi- 
cation and reflection processes of a mechanism. With such seman- 
tics, every expression evaluated in A is reified by all the mech- 
anisms. The evaluation semantics is then constructed by all the 
mechanism collaboratively with respect to the ordering. Given this 
alternative semantics, the program example in Listing|9|would pro- 
duce no exception independently of the ordering of afi and svft. 

6.2 Alternative Semantical Operations 

We illustrate our approach using expression evaluation semantics. 
However, the idea of third-party composition of aspect extensions 
can be realized for other kinds of semantical operations. 

Consider a generalized form of a semantical function type: 

Mean = OP Cont A 

where OP is a domain of operation identifiers. Given Cfg A = 
Cfg x Cfg*, Mean maps to various operations of MyBase se- 
mantics as shown in TableQ For example, store lookup operation 
is identified by location. It takes a store and a (dummy) value, and 
returns a store and a result value. Our approach can be easily rede- 
fined to use Mean instead of expression evaluation semantics. 

6.3 Other Solution Instances 

The specific EB wrapping semantics is only an illustration of our 
approach in general. In this sections we discuss how alternative 
solution instances can be constructed. 

The wrapping semantics enables to compose arbitrary aspect mech- 
anisms as long as the mechanisms can be defined as mixins to the 
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Type 


OP 


Cfg 


Expr. eval 


Exp 


Envp x Enw x Store 


Store upd 


Loc 


Store 


Store lookup 


Loc 


Store x Val 


Env upd 


Var 


Envv 


Env lookup 


Var 


Envv x Loc 



Table 1: Semantical operations in MyBase 



base mechanism description. However, wrapping does not sup- 
port complex mechanism compositions. For example, a reason- 
able composition of AspectJ and AspectWerkz might require that, 
at each join point, before advice in both AspectJ and AspectWerkz 
aspects are executed before any around advice, and finally fol- 
lowed by after advice. However, such an AspectJ/AspectWerkz 
composition is difficult to construct using the wrapping composi- 
tion semantics. 

More complex composition semantics can be provided by imposing 
additional requirements on the aspect mechanism design. For ex- 
ample, one possible approach is to specify types of aspectual effect 
that a mechanism can produce. With such a semantics, the over- 
all aspectual effect can be constructed from aspectual effects of the 
collaborating mechanisms with regard to the effect types. 

6.4 Other Mechanism Descriptions 

Our choice of the mechanism's description style restricts access to 
the context data. Specifically, a mechanism can only access ele- 
ments of the current or parent expression, environment, and stores. 
While this data can be sufficient for implementing the HisExti and 
HerExt2 aspect extensions for MyBase, real- world aspect exten- 
sions may generally require more information. For example, As- 
pectJ needs access to callee and caller objects to construct a method 
call join point. Instantiating the approach for a description style that 
uses an explicit representation of the evaluation context (e.g., using 
a CEKS machine I15II16I ) would produce a more general solution. 

In our solution we used annotated expressions to meet the granu- 
larity requirement of HisExti and HerExt2. The same result can be 
achieved by using small-step operational semantics for describing 
the mechanisms. In this case, aspect mechanisms would transform 
and extend operational semantics rules of the base mechanism. 

6.5 Application 

This work provides a foundation for composing multiple aspect 
mechanisms. A practical application of this work is to construct 
an AOP framework that: 

1. supports expressiveness that generalizes over concepts and 
lingual mechanisms of potential source aspect extensions. 
This requires a generalized aspect mechanism model. 

2. meets granularity requirements of any source aspect exten- 
sion. 

3. provides lingual mechanisms for encapsulating constructs that 
simulate a source aspect mechanism. 

4. provides lingual mechanisms for exposing the aspectual ef- 
fect of the source aspects. 



7. RELATED WORK 

7.1 Composing Aspect Extensions 

Several authors point out the expressiveness drawback in using a 
single general-purpose AOP language, and emphasize the useful- 
ness of combining modular domain-specific aspect extensions 1141 
1221 1481 l38l 1301 . However, the problem of composition has not re- 
ceived a thorough study. 

XAspects. Shonle et al. 1381 present a framework for aspect com- 
pilation that allows to combine multiple domain-specific aspect ex- 
tensions. The framework's composition semantics is to reduce all 
extensions to a single general-purpose aspect extension (AspectJ). 
Specifically, given a set of programs written in different aspect ex- 
tensions, XAspects produces a single program in AspectJ. An as- 
pect extension program is translated to one or more AspectJ as- 
pects. In XAspects, collaboration between the aspect extensions is 
realized as a collaboration between the translated AspectJ's aspects. 

The XAspects framework uses a translation-based approach. Specif- 
ically, XAspects translates programs in domain-specific aspect ex- 
tensions to AspectJ. Unfortunately, in the presence of other aspects, 
this approach does not preserve the behavior of the domain specific 
aspects, and therefore the XAspects approach does not guarantee a 
correct result. 

Moreover, extensions in XAspects must be reducible to AspectJ. 
Since only a subset of aspect extensions is expressible in AspectJ, 
XAspects doesn't achieve composition in general. Our approach 
to composition and collaboration is not based on translation. In 
comparison to XAspects our proposed approach is more general. 

Concern Manipulation Environment. IBM's new Concern Ma- 
nipulation Environment provides developers with an extensible plat- 
form for concern separation: "The CME provides a common plat- 
form in which different AOSD tools can interoperate and integrate" fTJ. 
CME would be a natural environment for a large scale application 
of our approach. 

7.2 AOP Semantics 

Existing works in AOP semantics explain existing aspect exten- 
sions and model AOP in general. We base some of our work on 
these studies. Unfortunately, they do not address the problem of 
aspect mechanism composition directly. 

Semantics for Existing AOP Languages. Wand et al.'s [49 1 se- 
mantic for advice and dynamic join points explains a simplified 
dynamic AspectJ. It provides denotational semantics to a small pro- 
cedural language, similar to ours. The language embodies key fea- 
tures of dynamic join points, pointcuts and advice. The seman- 
tics given does not express the AOP semantics separately from the 
base. However, advice weaving is defined there as a procedure 
transformer. This is a special case of a language semantics trans- 
former as we choose to define an aspect mechanism. 

Method-Call Interception 1271 is another semantical model that gives 
semantics of advising method calls. Similar to the previously dis- 
cussed work, it highlights a very specific piece of AOP expressive- 
ness (similar to AspectJ). 

Semantical Models of AOP. Several studies on AOP semantics 
provide a general model of AOP functionality. Walker et al. 1441 
defined aspects through explicitly labeled program points and first- 
class dynamic advice. Jagadeesan et al. 1241 use similar abstrac- 



14 



tions (pointcuts and advice). Clifton et al. 1 101 1111 provides pa- 
rameterized aspect calculus for modeling AOP semantics. In their 
model, AOP functionality can be applied to any reduction step in 
a base language semantics. This is similar to the definition of an 
aspect mechanism we use. 

In comparison to our semantics, these models define AOP function- 
ality using low-level language semantics abstractions. Using these 
more formal approaches for describing our method is left for future 
work. 

Modular Semantics for AOP. We define an aspect mechanism 
separately from the base language and require it to specify only 
the AOP transformation functionality. This approach leads to the 
construction of modular AOP semantics. Exploring the application 
of other approaches for modular language semantics (e.g., modular 
SOS 1311 and monad-based denotational semantics) to describing 
aspect mechanism is another area for further research. 

8. CONCLUSION 

In this paper we address the open problem of integrating a base lan- 
guage Base with a set of third-party aspect extensions Exti , . . . , Exf 
for that language. We present a semantical framework in which in- 
dependently developed, dynamic aspect mechanisms can be subject 
to third-party composition and work collaboratively. 

We instantiate our approach for aspect mechanisms defined as ex- 
pression evaluation transformers. The mechanisms can be com- 
posed like mixin layers |39H34ll35l in a pipe-and-filter architecture 
with delegation semantics. Each mechanism collaborates by dele- 
gating or exposing the evaluation of expressions. The base mecha- 
nism serves as the terminator and does not delegate the evaluation 
further. 

We applied our approach in the implementation of a concrete base 
language MyBase and two concrete aspect extensions to that lan- 
guage: HisExti and HerExt2. The implementation illustrates the 
constructions steps. It demonstrates the semantics for third-party 
composition of aspect mechanisms. 

The semantics for HisExti resembles that for AspectJ. Indeed, our 
approach can be applied to implementing the pointcut and advice 
mechanism of AspectJ as an aspect extensions to Java. More- 
over, our approach is not limited to the pipe-and-filter composi- 
tion architecture. Introduction of a generalized aspect mechanism 
model would enable sophisticated compositions of third-party as- 
pect mechanisms. This would further provide a practical way to 
compose AspectJ with new domain-specific aspect extensions. 
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